The Atari Compendium/The Atari Compendium (Toad Computers) (1994).iso/files/umich/telecomm/fnordadl/fn132src.zoo/ref-man/network.tex

Text File | 1991-09-02 | 80.2 KB | 1,956 lines

@comment Tell Emacs to use -*-texinfo-*- mode
@comment $Id: network.tex,v 2.6 91/09/02 01:37:53 adrian Exp $

@node Networking, Doors, Events, Top
@chapter Networking
@cindex Networking

Fnordadel has the ability to
@cindex Network
@dfn{network}, that is, to share mail,
rooms and files, with other Fnordadels and other Citadels supporting
the ``C86Net'' style of networking.  Since Fnordadel is a descendant
of Citadel-86, it retains compatibility with Citadel-86 networking
(well, mostly---@pxref{Networking with Citadel-86}).
Other Citadel variants supporting C86Net
include STadel (Fnordadel's immediate ancestor), Citadel-68K for the
Amiga, Fortress, and some others.

When two Citadels network, they follow a standard procedure.
First, one must call the other.  Fnordadel can be induced to make net
calls by means of
@vindex event
@code{#event}s and
@vindex polling
@code{#polling}; read
further in this chapter for
more on these.  Fnordadel can also receive net calls from any system at
any time (assuming there's no user logged in, of course.)  When two
Citadels have connected for the purposes of networking, they first must
stabilize the call, the caller (which starts out as the
@dfn{master}) must
@cindex Master (network mode)
identify itself, and passwords, if you use them, must be exchanged.  Then the
caller makes a series of requests; these can be for room sharing, file
sending or requesting, mail delivery, or whatever.  After the caller has made
all of its requests,
@cindex Role reversal
@dfn{role reversal} is performed; this essentially makes
the caller and the callee switch roles in mid-call, leaving the callee as
the master and the caller as the
@cindex Slave (network mode)
@dfn{slave}.  The callee now issues any
requests that it has to make in the same manner as the caller did.  When
the callee is finished, the two systems hang up.

Simple, huh?  Well, as it happens, this simple system has proven
quite flexible and useful; networking has become a fairly large part of
Citadel activity.  So it's only natural that it's had a large amount of
programming effort devoted to it, and thus, a lot of stuff we've got to
tell you about it. So hang on to your hat, and off we go!

@node Networking Configuration, The Net Menu, Networking, Networking
@section Networking Configuration
@cindex Networking configuration
@cindex Configuration, networking

There is a whole whack of things that either need to be set or
can be set in @file{ctdlcnfg.sys} to control Fnordadel's networking ability.
We divide these into two groups: required parameters and optional ones.
Please note that there is no way to ``turn off'' Fnordadel's networking
ability.  You may choose not to explicitly network with any systems, but
other Citadels will still be able to call yours and send you mail, at
the very least.

@node Required parameters, Optional parameters, Networking Configuration, Networking Configuration
@subsection Required parameters

These parameters @emph{must} be defined properly in @file{ctdlcnfg.sys}
for proper networking to occur; indeed, Fnordadel will stubbornly refuse to
come up at all unless certain ones are defined.  So define all
these.

@table @code
@item #nodename
@vindex nodename
@cindex Network node name
@cindex Node name
This is a string of 19 characters or less.  It
defines the name by which your system will be known on
the network.  The allowable characters in this string are:
@itemize @bullet
@item
Upper and lower case letters
@item
Digits
@item
Space characters (@samp{ })
@item
Any of @samp{* _ - .}
@end itemize
@noindent
Spaces are equivalent to @samp{_} (underscore) characters; therefore
@samp{The_Rock} and @samp{The Rock} amount to the same thing.  (We
encourage the use of @samp{_} rather than @samp{ }; aside from our entirely
subjective opinion that it looks better, it also helps when interfacing
with other networks that might not support spaces in nodenames.)
We'd also like
to recommend against using @samp{.} in your
@vindex nodename
@code{#nodename}; it may
cause confusion with domains in later versions of the
software.

We'd like it if
@vindex nodename
@code{#nodename}s were kept to nine
characters or less; indeed, @code{configur} will preach at
you a bit if you define a
@vindex nodename
@code{#nodename} with more than nine
characters.  This is mainly because of mail routing
considerations (@pxref{Mail Routing}); explicitly addressing
mail to systems with long weird nodenames is a pain, and
prone to error.  We'd prefer that you used a short
@vindex nodename
@code{#nodename} together with a descriptive
@vindex organization
@code{#organization}
(@pxref{Optional parameters}.)

@item #nodeid
@vindex nodeid
@cindex Network node ID
@cindex Node ID
This string, limited to 19 characters, defines the
unique ID by which your node will be known.  It is used
by the internals of the networking software, so it will
never be shown directly to users.

What can this unique string consist of, you ask?
Why, it's no more than your telephone number.  It must follow
a strict format:
@example
<@var{country code}> <@var{area code}> <@var{phone number}>
@end example
Country codes are listed in @ref{Country Codes}.  (Canada
is @samp{CA}, and the United States is @samp{US}.)  The area code and
phone number are what you'd expect.  Punctuation (dashes,
parentheses and so on) are allowed; they're stripped when
the string is actually used for anything.  As an example,
the following is @code{secret}'s
@vindex nodeid
@code{#nodeid}:
@example
#nodeid "CA [phone]"
@end example

@item #define sharedrooms
@vindex sharedrooms
@cindex Room sharing limit
This variable defines the maximum number of rooms
which may be shared with any one system on your net-list.
The limit has historically been 16; this value should be
perfectly adequate for most systems.  If you're sharing a
lot of rooms (say, you're a major hub system), you'll want
to put this higher.  Each shared room slot occupies 10
bytes for each node in your net-list.

Once you've
configured your system for the first time,
@code{sharedrooms} can only be changed
@pindex nchange
by running @code{nchange}; see @file{nchange.man} for more.  Do @emph{not}
simply change the value in @file{ctdlcnfg.sys} and run @code{configur};
@pindex configur
things will either come to a screeching halt (if you're
lucky), or blow up violently (if you're not).

@item #netdir
@vindex netdir
@cindex Network files directory
This is the directory in which Fnordadel will
put all the files needed in networking; these files will
include @file{ctdlnet.sys} (your net-list), @file{ctdlloop.zap} (the
loop-zapper database; @pxref{The loop-zapper}), and many
files of a temporary nature.  Make sure this directory is
on a device with some amount of free space (i.e., don't try
to cram it on a floppy which has 3k free) because the
temporary files written here can sometimes be fairly large
if you do a lot of networking.

Note that
@vindex spooldir
@code{#spooldir} is a synonym for
@vindex netdir
@code{#netdir}.
@end table

@node Optional parameters, Setting up for networking, Required parameters, Networking Configuration
@subsection Optional parameters

Many of these parameters are of the ``nice to have, but
not absolutely necessary'' variety.  Fnordadel will try to use
reasonable defaults where applicable.

@table @code
@item #organization
@vindex organization
@cindex Network organization name
@cindex Organization name
To make up for short
@vindex nodename
@code{#nodename}s (@pxref{Required parameters}),
you may define a string of up to 39
characters which will be used to provide a slightly better
description of your system in networked messages.  It is
displayed at the end of message headers in shared rooms.
For example, let's say we're running a @sc{bbs} called
``The Round Table''.  Now, this is longer than 9 characters,
so we don't want to use it as-is for a
@vindex nodename
@code{#nodename}.  So, we define
@vindex nodename
@code{#nodename} as @samp{RT}, which is easy to remember and type, and
use an
@vindex organization
@code{#organization} like this:
@example
#organization "The Round Table, Edmonton"
@end example
The headers on messages from our board will appear
like this:
@example
90Jul20 8:24 pm from Biff @@ RT (The Round Table, Edmonton)
@end example
@vindex organization
The @code{#organization} field can say anything, really;
some people like to put witty little sayings in there or
whatever.  Just keep it clean.

@item #domain
@vindex domain
@cindex Domains
@cindex Network domains
The @code{#domain} field tells the system what Citadel-86-style domain
your system belongs to.  A domain is a group of network systems, usually
organized by geographical region, but the grouping could be based on
anything at all.  If you don't know what domain you're a part of, leave
this field commented out or define it to be the empty string (i.e.
@code{#domain ""}).  You can set the field later.

This field is
primarily for Citadel-86 compatibility, which uses state or province
abbreviations as domains.  Ask around your area to see if a domain exists,
and join it if so.  If not, start your own, or join a domain from another
region.  Please don't put a junk value in this field; leave it blank
unless you're joining or starting a real domain.  @xref{Domains}.

If you define a domain, it will appear in the headers of messages
originating on your system.  The domains of other systems will appear
in message headers from those systems.
Continuing the example from above, with system RT, if we define
@vindex domain
@code{#domain} as @samp{Alta}, message headers will look like this:
@example
90Jul20 8:24 pm from Biff @@ RT.Alta (The Round Table, Edmonton)
@end example

@vindex receiptk
@cindex Network file receipt limit
@vindex receiptdir
@cindex Network file receipt directory
@item #define receiptk
@itemx #receiptdir
Since Fnordadel can accept files sent from other
systems on the network, we have to tell it how much we're
willing to accept, and where to put these files.

The variable @code{receiptk} should be defined as the
number of kilobytes which will be allowed to accumulate in
your receipt directory before Fnordadel will refuse to
accept any more files over the network.  Notice that this
really doesn't have anything to do with the amount of free
space available on your storage device, though obviously
if you run out of space, files will not be received.  What
actually happens is that prior to the receipt of a file,
Fnordadel will add up the sizes of the files currently
in your receipt directory and compare the number with
your defined @code{receiptk}; if the addition of the new file
would cause the total amount of used space to
exceed @code{receiptk}, then the file will be refused.
The upshot: clean out your receipt directory after you
receive files from other systems.

@vindex receiptk
@code{#receiptk} defaults to @samp{100}.

@vindex receiptdir
@code{#receiptdir} is, as you'd expect, the name of the
directory in which to put received files.  If you do not
define it, it defaults to
@vindex netdir
@code{#netdir}.

@item #define allnet
@vindex allnet
@cindex Network privileges
This simple binary switch tells Fnordadel whether
you want to give out net privs to all new users.  If set
to @samp{1}, all users will be given net privs when their account
is created; when set to @samp{0}, the Sysop must explicitly grant
net privileges individually (@pxref{User Status Commands}).
See @code{[N]et-save} in @ref{The Message Editor}, and
@code{.E(nter) N(et-message)} in @ref{Multi-key message entry commands}, for
a description of what the possession of net privs allows a user to do and how.
See also @file{flipbits.man} for a description of a utility to set the
@pindex flipbits
net privilege flag for all users en masse.

@vindex netlog
@cindex Network activity log
@vindex netdebug
@cindex Network debugging
@item #define netlog
@itemx #define netdebug
These two binary switches set Fnordadel defaults
for network logging and debugging.  If set to @samp{1}, then the
logging/debugging is automatically turned on when you run
Fnordadel.  @xref{Logging and Debugging}.

@item #define zaploops
@vindex zaploops
@cindex Loop zapping
This binary switch tells Fnordadel to enable or
disable the loop-zapper.  The loop-zapper is used to
control
@cindex Vortex
@dfn{vortexes} in networked rooms; that is, the
phenomenon whereby erroneous backbone connections
somewhere along the network result in duplicate messages
being sent to your system.  @xref{The loop-zapper}.
Suffice it to say that
setting @code{zaploops} to @samp{1} will enable it; to @samp{0} will disable
it.

@pindex +zap (citadel)
The @code{citadel} command line switch @samp{+zap} is
another way to enable the loop-zapper.

@item #define purgenet
@vindex purgenet
@cindex Purge messages (network)
This binary switch, if set to @samp{1}, tells Fnordadel to use its
message purge feature on incoming network traffic, as well
as locally-entered messages.  For more information on the
purge feature, @pxref{Message purging}.  In a nutshell, the feature
lets Fnordadel automatically delete messages from undesireable
users or entire net nodes, which you specify.  Use with caution.

@item #define keepdiscards
@vindex keepdiscards
@cindex Discarded messages
@cindex Loop zapping
@cindex Purge messages (network)
This binary switch controls Fnordadel's treatment
of incoming net messages that are discarded, either by the
loop-zapper (@pxref{The loop-zapper}) or the message purger (see
above).  If set to @samp{1}, the flag instructs Fnordadel to keep
discarded messages in the
@vindex netdir
@code{#netdir}, for you to look at later.
At that time you may do such things as delete them or integrate
them into the message base.  @xref{The Net Menu}, for more
details on the commands to handle discarded messages.

If the flag is set to @samp{0}, messages discarded by the
loop-zapper or message-purger are lost forever.

@item #define forward-mail
@vindex forward-mail
@cindex Mail forwarding
@cindex Network mail forwarding
Another switch.  If set to @samp{1}, it tells Fnordadel
to allow mail to be forwarded through your system to
others.  If, for some reason, you want to disallow mail
forwarding, set @code{forward-mail} to @samp{0}.  @xref{Mail Routing}.

@item #define anonnetmail
@vindex anonnetmail
@cindex Network mail
This binary switch, if set to @samp{1}, allows your system to
receive net-mail from systems that are unknown to it.  This is
the default behavior of the system.  If you have unwanted
volumes of mail being dumped on you by mystery nodes, you can
set this parameter to @samp{0} and Fnordadel will reject netmail from unknown
systems thereafter.

@item #define anonfilexfer
@vindex anonfilexfer
@cindex Network file transfers
This binary switch is like the one above, but controls
file transfers with anonymous nodes.  If the flag is set to
@samp{1}, file transfers to and from unknown nodes are permitted.  If
set to @samp{0}, they are prevented.

@item #define pathalias
@vindex pathalias
@cindex Path aliases
Here's yet another binary switch; when @samp{1}, it
enables Fnordadel's path aliasing capability.  @xref{Mail Routing}.

@item #hub
@vindex hub
@cindex Network hub
@cindex Mail forwarding
@cindex Network mail forwarding
This is a string variable which should be set
to the nodename of the system to which undeliverable
mail is to be forwarded (which system, hopefully, will
be better equipped to deal with it than yours is.)
@xref{Hubbing}, for more information on
@vindex hub
@code{#hub}.

@vindex ld-cost
@cindex Mail cost
@cindex Network mail cost
@vindex hub-cost
@cindex Mail cost
@cindex Network mail cost
@item #define ld-cost
@itemx #define hub-cost
These integer variables define the cost, measured in ld-credits, of using the
Fnordadel long-distance mail routing and hub forwarding facilities,
respectively.  Ld-credits are given to users by the Sysop (see
@ref{User Status Commands}, for how to do so), and control who can send mail
that costs you money.
@end table

@node Setting up for networking, Related parameters, Optional parameters, Networking Configuration
@subsection Setting up for networking

Networking proceeds in one of two ways: your system can call another one, or
other systems can call yours.  Usually you'll do both, for local network
connections; for long-distance ones, you'll want to make specific arrangements.
There are two mechanisms for achieving networking: events, and polling.

@node Network events, Polling, Setting up for networking, Setting up for networking
@subsubsection Network events
@cindex Network event

If you don't know about events yet, go read
@ref{Events}.  As they relate to networking, events allow
you to schedule network sessions, during which your @sc{bbs}
will presumably call other systems (or be called by
other systems) for the sole purpose of networking.

The format of the event definition is laid
out in @ref{Events in General}; here we present an example only, with
a couple of points of note:
@vindex event
@example
#event NETWORK all 3:01 39 ld-net 1
@end example
The above line will set up a network event which
goes off at 3:01 in the morning, lasting for 39 minutes;
it will be named @samp{ld-net}; and it will apply to network
#1.  This means that your system will call only those nodes
that are part of net #1 during this session, though calls
@emph{from} all systems will be accepted.

During a network event, the @sc{bbs} is closed to the
users.  If a user connects, he will, after a delay, be
shown a message to the effect of ``The system will be in
net mode for @var{xx} minutes longer; call back later.'' If a
user is logged in before an event is scheduled to go off,
he will be warned five minutes beforehand that he'd better
terminate quickly.  When the event arrives, he will be
booted unceremoniously.

Upon commencing a net event, Fnordadel will call
all systems in the specified net for which there is
outgoing material.  In addition, you can configure things
so that certain nodes will be called whether there is work
or not; this is known as ``polling''.  (Note that this is
different from
@vindex polling
@code{#polling}, detailed in @ref{Polling},
below; we really must change the terminology@dots{})  See the @code{[F]}
command in @ref{Editing Nodes}.

Note that the event will always last the specified
number of minutes, whether the @sc{bbs} has finished calling
systems or not.  Indeed, you may want to set up a net
session for the sole purpose of reserving a time slot for
other systems to call yours.  (As we've mentioned before,
Fnordadel can receive network calls at any time, whether
it's in a network event or not.  But setting up an event
ensures that no user will be logged in.)

@node Polling, Summary of network events and polling, Network events, Setting up for networking
@subsubsection Polling
@cindex Network polling
@cindex Polling, network

@dfn{Polling}, in this context, refers to the ability
of Fnordadel to dynamically enter network mode whenever
there is outgoing work and the @sc{bbs} has been idle for a set
length of time.  This allows greater flexibility than does
the network event mechanism.

Essentially, we must tell Fnordadel the time
periods during which we want polling to be active; we must
also tell it the required length of idle time before
systems will be polled.  The syntax of the
@vindex polling
@code{#polling}
definition is as follows:
@cindex Polling declaration
@example
#polling <@var{net}> <@var{start-time}> <@var{end-time}> [@var{days}]
@end example
@noindent
The fields mean:
@table @var
@item net
The net number to poll (usually 0).
@item start-time
The time (in 24-hour format) to start polling.
@item end-time
The time to end polling.
@item days
An optional field which is either
@samp{all}, or a comma-separated list of days, as in
@samp{Mon,Wed,Fri}.
@end table
Most systems that engage in any local networking
put a fairly standard
@vindex polling
@code{#polling} line in:
@example
#polling 0 0:00 23:59 all
@end example
This causes the @sc{bbs} to poll network number 0 all
day long.

You can also define more than one
@vindex polling
@code{#polling}
duration; for example,
@example
#polling 1 4:00 20:00 all
#polling 2 20:01 3:00 all
@end example
@noindent
will cause net #1 to be polled from 4AM to 8PM, and net
#2 to be polled from 8:01PM to 3AM.

If you've got any
@vindex polling
@code{#polling} defined, you'll also
want to define the variable @code{poll-delay}.  This is the
length of time, measured in minutes, for which the @sc{bbs}
must be idle before Fnordadel will start polling.  A
decent value (or, at least, what we use) is around 15
minutes.

@node Summary of network events and polling,  , Polling, Setting up for networking
@subsubsection Summary of network events and polling

Most systems that engage in only local networking
find that
@vindex polling
@code{#polling} is perfectly adequate for
decent propagation times; setting up network events
is usually unnecessary.  Of course, if you've got users
calling within 30 seconds after the previous one hangs
up, you won't get much polling done; but we've never
seen a system that doesn't have idle time scattered
throughout the day.

If you do any long-distance networking, you'll
probably want to use a mixture of network events for
the long-distance stuff and polling for the local stuff.
It would be distinctly unwise to set up polling
for nets containing long-distance systems; you don't
want your board calling cross-country every time someone
enters a message in the applicable shared rooms, do you?
Instead, set up an event during the wee hours of the
morning, and get all the long-distance networking done
then.  You might want to coordinate things with your
long-distance connection; if both of you jump into a
network event at the same time, things will go quicker.

@node Special net keys
@subsubsection Special keys in network events
@cindex Special net keys
@cindex Commands during network events

There are a couple of special keys that you can hit while Fnordadel is in a
network event to make it do things.  You can use these only when Fnordadel
isn't in the middle of an actual net call.

@table @samp
@cindex Background process, Fnordadel as a
@findex ^Z (send Fnordadel to background)
@item ^Z
@dfn{Take Fnordadel to the background}.  If you run Fnordadel under some sort
of multitasker, hitting @samp{^Z} while in a network event causes the same
thing as when you hit it any other time---it causes Fnordadel to drop into
the background.  @xref{Multitasking and Fnordadel}.

@cindex Quit Fnordadel in net mode
@findex Q (quit Fnordadel in net mode)
@item Q
@dfn{Quit Fnordadel}.  Hitting @samp{Q} while in a net event causes Fnordadel
to exit completely, after confirmation.  This is a good way to stop the
system from calling those long-distance systems 100 times during the day.
@end table

@node Related parameters,  , Setting up for networking, Networking Configuration
@subsection Related parameters

There are a few other parameters that aren't strictly
networking parameters, but which will cause you networking grief
if they aren't defined properly.  They have to do with your
modem; @pxref{Modem Stuff}, for detailed descriptions.  Ones to watch:
@example
#define usa
@vindex usa
#define local-time
@vindex local-time
#define ld-time
@vindex ld-time
@end example

@node The Net Menu, Editing Nodes, Networking Configuration, Networking
@section The Net Menu
@cindex Network menu
@cindex Commands, networking configuration

The Net menu hides under the Sysop menu, which is reachable by
hitting @samp{^L} at a room prompt.  (@xref{Sysop Special Functions},
for more on Sysop commands.)
If you hit @samp{N} at the @samp{sysop cmd:} prompt, you'll be in the Net menu, from
which you can choose one of the following commands:
@cindex Network menu
@example
[A]dd node
[D]iscarded messages
[E]dit node
[F]orce poll to node
[P]oll network
[R]equest file
[S]end file
[V]iew net list
e[X]it to sysop functions
@end example

@table @code
@item [A]dd node
This command allows you to add new nodes to your net-list;
you must add a node to your net-list before you can send @emph{anything} to it.

You will first be asked for the node's name; type its
nodename (the hopefully short name by which the other node is
known.)  If the system is a Citadel-86, it probably has a long
and twisted name, so make sure you've got it spelled
correctly, or things like mail routing, auto-reply to incoming net-mail,
and other stuff won't work quite right.  Names will never exceed 19
characters, in any case.  Then, it'll ask you for the node ID of
the new system.  This is the node's phone number; it is, obviously,
vitally important to get this right.  It should be in the same format
as your own
@vindex nodeid
@code{#nodeid} (@pxref{Required parameters}).

Next, you'll be queried about the baud rate supported by
the new node; enter the standard baud rate code (@samp{0} is 300, @samp{1} is
1200, @samp{2} is 2400, @samp{3} is 9600 and @samp{4} is 19200).  Use
the highest baud rate
supported by the other node, even if it is higher than the highest
baud rate that yours supports.  Fnordadel is smart enough to pick
the lower of the two when it dials out; and this way you don't have
to edit your net-list if you happen to acquire a faster modem.

Lastly, Fnordadel will ask you whether the system is
a long-distance node or not.  Make sure you tell the truth here;
this setting affects a number of things, including the method by
which dialout is done.  (@xref{Long-distance dialing}.)

The rest of the settings for the new node will default to
(hopefully) reasonable values.  In some cases you'll have to
immediately edit the node to set other things like net passwords,
Citadel-86 status, and so on.

@item [D]iscarded messages
@cindex Discarded messages
This command gets you into a small sub-section where you can
view and deal with incoming net messages that were zapped or purged
by your system, if you configured things to save such messages.
(@xref{Optional parameters}, for the way to configure this;
@pxref{The loop-zapper}, for details on the loop-zapper;
and @pxref{Optional parameters}, and @ref{Message purging}, for details on
the message purge feature.)  After
hitting @samp{D}, the system will either tell you there are no discarded
messages, or it will tell you the number of
discarded messages, show you the first one, and then give you the
following prompt:
@example
[A]gain, [D]elete, [I]ntegrate, [N]ext, [S]top:
@end example
@table @code
@item [A]gain
Redisplay the current message and prompt again.
@item [D]elete
Delete the current discarded message, if you confirm your desire to
do so, and advance to the next discarded message, if there is one.
@item [I]ntegrate
This is the interesting command.  If you confirm the
action, this tells Fnordadel to integrate the current discarded
message into your message base as though it had never been
zapped or purged.  It will be passed along to any backbone
systems sharing the room, just as it normally would have been.

You might run into difficulty if the message was in a
room that no longer exists on your system, or whose name has
been changed.  The same is true if the message came from an
STadel or derivative, and the room is aliased there to something
other than the name in use on your system, or if the room is
aliased to a different name on your own system (@pxref{Shared room aliasing}).
In any of these cases, Fnordadel won't know where to put the
message now, so it will ask you if placing the message in the
@code{Aide>} room is okay.  Once it's there, you can move it.  If you
don't okay the placement in @code{Aide>}, nothing is done.

If the message is successfully integrated into a room,
you will be asked if the discard message file should be deleted,
and then shown the next discarded message, if there is one.
If the message is not integrated, you will be returned to the
discard prompt.
@item [N]ext
Take you to the next discarded message, if there is one.
@item [S]top
Stop the discard message processing and return you to the net commands menu.
@end table

@item [E]dit node
This command takes you to the net node edit sub-menu.
@xref{Editing Nodes}, for an in-depth look.

@item [F]orce-poll node
This is a quickie command for forcing Fnordadel to make
a single net call to another system.  Supply a system name, and
Fnordadel will call the system regardless of traffic pending,
receive-only status, l-d status or anything else.

@item [P]oll network
This command allows you to force a one-time poll of the
specified network.  If anyone is logged in at the time, they will
be immediately terminated (with extreme prejudice, we might
add) and Fnordadel will call all nodes in the specified net
for which there is work.

@item [R]equest file
Use this command when you wish to get some files from some
system with which you network directly.  You'll be asked for the
system from which to request files, the room on the other system
from which to get them, the filename(s) to get, and the directory
on your system in which to place the received files.  The room on
the other system must be ``network readable'' (@pxref{How to share a room})
for the request to work.  You may use wildcards (@samp{*} and @samp{?}) in the
filename specification.

The file request will be spooled for later; the next time
your system connects with the other one, the request will be made
and, if the other system can oblige, the files will be transferred.

Note that it is possible to request files from a system
with which you have not previously networked.  Simply add the node
to your net-list in the standard manner, and @samp{[R]equest} the file as
usual---the other node doesn't have to know about yours.  (We use
this in the distribution of Fnordadel; any other node can call
us and request new versions, assuming they know the name of the
room and the filenames.  @xref{Fnordadel Support}.)

@item [S]end file
This command allows you to send a file or files to a node
with which you network directly.  You'll be asked for the target
node name and the name(s) of the file(s) to transfer; you should
provide the full path-spec, and wildcards (@samp{*} and @samp{?}) are permitted.
The sendfile will be spooled for later; the next time your system
connects with the other one, the sendfile will be made, subject
to space availability on the other system.  If there wasn't enough
space, the other node will say so and you'll get a message in
@code{Aide>} to this effect.  You will have to re-enter the send command
once the remote system has corrected its space problems.

@item [V]iew net list
This prints out a nicely formatted list of all the nodes
in your net-list.  The format is as follows:

@example
@group
* sysname              CA 403 432 1098      CRMF  2400 0,1
^       ^               ^                    ^      ^   ^
|        \              |                    |      |   |
"need     the name of   the nodeId      various   baud  |
to call"  the node     (phone number)    flags    rate  |
 flag                                                   |
                                                        |
                            nets to which the node belongs
@end group
@end example

The ``various flags'' may consist of one or more of the
following:
@table @samp
@item C
The system is a Citadel-86
@item R
The system is receive-only (i.e., your system will
never call it)
@item M
There is mail pending
@item F
There are file sends/requests pending
@end table
The ``need to call'' flag (the leading asterisk) appears if
there is any work pending for the node; it doesn't mean that your
system will call the node, because the node may be set to receive-only.
(@xref{Editing Nodes}.)

@item e[X]it to sysop functions
This should be blatantly obvious.
@end table

@node Editing Nodes, Roomsharing, The Net Menu, Networking
@section Editing Nodes
@cindex Editing network nodes
@cindex Nodes, network, editing
@cindex Network nodes, editing

There is a sub-menu under the Net menu (which is itself a sub-menu
under the Sysop menu; @pxref{The Net Menu}) which allows you to edit
various things pertaining to nodes in your net-list.  Nodes must obviously
be added to the list before they can be edited, using the @code{[A]dd node}
command; again, @pxref{The Net Menu}.
The commands on the node edit menu are as follows:
@cindex Network node edit menu
@cindex Node edit menu
@example
[A]ccess setting
[B]aud setting
[C]- set receive-only status
L[D] role reversal
[E]xternal dialer setup
[F]- set polling days
[I]D change
[K]ill node from list
[L]ocal setting
[N]ame change
[P]assword settings
[R]ooms shared
[T]oggle Cit-86 status
[U]se nets
[V]iew node configuration
e[X]it net editing
[Z]- set l-d poll count
@end example

@table @code
@item [A]ccess setting
An access string is an alternate way of dialing a system.
Normally, the dial command for the modem is formed by taking the
last seven digits of the node ID (for local systems), or the full
ten digits, i.e., including the area code, prefixed by a @samp{1} (for
long-distance systems), and sandwiching this between the dial
prefix and the dial suffix.  (This all assumes that you've got
@vindex usa
@code{#usa} defined in @file{ctdlcnfg.sys}; see @ref{Dialing out},
for more on this stuff.)

But if you specify an access string, Fnordadel forgets
all of the above, and simply spits the access string at the modem
(still sandwiched between the dial prefix and suffix.)  You'd use
this if you're dialing a country other than Canada or the USA, for
instance, or if you're dialing a system which is long-distance but
within your area-code. (Some telephone systems don't like it if you
dial 1-@var{areacode}-@var{number} within the @var{areacode}.)  Because the
string is used as-is, you can embed any special dialing commands
that your modem supports, like @samp{,} to pause the dial or whatever.

The access string is also used as a command line to pass
to an external dialer that you may have set up for this node; see below.

@item [B]aud setting
This allows you to change the node's baud rate.  The
acceptable values here are the same as elsewhere in Fnordadel:
@samp{0} is 300 baud; @samp{1} is 1200 baud; @samp{2} is 2400 baud;
@samp{3} is 9600 baud;
and @samp{4} is 19200 baud.  Note that Fnordadel will never attempt
to call out at a baud rate higher than the highest rate supported
on your system; so it's perfectly safe to list a system at 19200
baud if you're only running on a 2400 baud modem; one day, you
too may have a 19200 baud modem, and when you do, your @sc{bbs} will
be ready for it!

@item [C]- set receive-only status
A node can be set to
@cindex Receive-only (net node status)
@dfn{receive-only}, which means that
Fnordadel will never dial out to it, even if there is work
pending for that system---you'll have to wait until the other
system calls yours.

If you're entering nodes into your net-list for the sole
purpose of dialing out to them manually using the @code{[T]elephone} command,
(i.e., they aren't Citadels), then set receive-only status to prevent an
accidental network callout.

@item L[D] role reversal
This is somewhat of an outdated command; it allows you
to specify whether role-reversal will be performed with this
(presumably long-distance) system.  It defaults to Yes, so you
should never have to muck with it.

@item [E]xternal dialer setup
Fnordadel allows you to define an external dialer for
each net node; that is, a program which will do the work of
dialing and connecting with the system.  The main use for this
is if you're using some sort of service like PC-Pursuit, or a
packet-switched network, or whatever.  When using this command,
specify the external dialer number; Fnordadel expects to find
the external dialer programs in your
@vindex netdir
@code{#netdir}, named
@file{dial_@var{n}.prg},
where @var{n} is the dialer number.  If you have an external dialer
set for a node, it will use the access string as
the command tail to pass to the dialer.

So, say you're using PC-Pursuit.  You've taken the
PC-Pursuit dialer program and put it in
@vindex netdir
@code{#netdir} as @file{dial_1.prg}.
You've set the external dialer (using the [E] command) to "1".
You've set the @code{[A]ccess} string to @samp{-x foobar}.  When Fnordadel
dials this node, it will run the program so:
@samp{#netdir\dial_1.prg -x foobar}.
When the dialer program finishes, there should be a
carrier present and the baud rate should be set up correctly,
assuming the call connected.  Fnordadel will then proceed
with networking as normal.

@item [F]- set polling days
Despite the fact that this command has the word ``polling''
in it, it in fact has nothing to do with
@vindex polling
@code{#polling} (the ability
to make net calls at any time.)  Rather, this command lets you
specify the days on which the net node will be called @emph{whether
there is work pending or not}.  The calls will still happen only during
applicable network events.  This allows you to, say, regularly
call a long-distance network feed to pick up stuff,
even when there is no outgoing work pending.

The format of the days specification is any of @samp{Mon},
@samp{Tue}, @samp{Wed}, @samp{Thu}, @samp{Fri}, @samp{Sat} and @samp{Sun},
separated by commas.
So @samp{Mon,Wed,Sat} is a valid specification.  (This format is the
same as that used in the
@vindex event
@code{#event} and
@vindex polling
@code{#polling} definitions;
see @ref{Networking Configuration}.)

@item [I]D change
When a system with which you network changes its phone
number, you'll have to make the change in your net-list, and this
is how.  Just enter the standard node ID format:
@example
<@var{country}> <@var{area code}> <@var{number}>
@end example
@noindent
as in @samp{CA 403 425 1779}.

Note that if you change the node ID of
a system, the loop-zapper records for that node will be
invalidated.  The loop-zapper will pick up the change as a matter
of course (it will look like a new system, as far as the loop
zapper is concerned), so this isn't a problem or anything.

@item [K]ill node from list
This command will remove a node from your net-list.
Simply type its name; Fnordadel will ask you for confirmation
before it kills the node.

Currently Fnordadel does not unshare all the rooms
that this system was sharing; you must do so manually before using
this command, or things may screw up later on.  (Edit the room and
type @samp{U}; see @ref{Sysop room-editing commands}, and
@ref{How to share a room}.)
The confirmation prompt will remind you of this fact, in case you forgot.

@item [L]ocal setting
This command is for telling Fnordadel whether this
system is long-distance (i.e., out of your local calling area) or local.
You do want to be accurate with this; don't fib.

@item [N]ame change
If the node has changed its nodename, you'll want to
make the corresponding change in your net-list to keep everything
working smoothly.  Just type in the new name.

@item [P]assword settings
If you suspect security problems when networking with this
node, then set the passwords.  They must be agreed upon by you and
the other Sysop beforehand.  You'll define the password that your
system uses when calling the other one, and the password that your
system should expect from the other when it calls you.  They may be
the same, though for optimum security you'd want them different.

Please note that Citadel-86 systems use a different form of
net passwords, and therefore you must tell Fnordadel that this node is a
Cit-86, or passwords will not work.  See @code{[T]oggle Cit-86 status}, below.

@item [R]ooms shared
This command prints out a list of the rooms that your
system is sharing with this node.  Rooms with messages that need
to be sent to the node are flagged with an asterisk.

@item [T]oggle Cit-86 status
Actually, it's not a toggle, but @code{[C]} was taken.  Anyway,
if the node is a Citadel-86 system, you should tell Fnordadel
so by using this command.  The value of this flag is checked for
things like file requests, network protocol changes, and net
passwords, so it is
essential to turn the flag on for Citadel-86es.  Note that direct
Cit-86 derivatives like Citadel-68k for the Amiga are functionally
identical to Cit-86 (as far as networking goes) so you must turn
this flag on for them as well.

@item [U]se nets
Fnordadel uses the concept of
@cindex Network groups
@dfn{net numbers} to form logical groups of
systems.
When you first enter a net node into your net-list, it
defaults to being a member of net number 0.  But you can set it
up so that it's a part of a different net, or several nets at
once---valid net numbers are from 0 to 31.  These net numbers are
referred to in network event definitions (a node must be part of
the net to which the net event applies for Fnordadel to call the
node during the event) and in polling (which applies to specific
net numbers).  You may also remove a node from all nets; this
has the effect of removing it from the standard list of valid net
nodes printed out when a user hits @samp{?} when asked for the target
system of a piece of net-mail; and also removes it from
consideration when the system is trying to route net-mail
(@pxref{Path aliasing}).

The format of the @code{[U]se nets} specification is as follows:
To add a node to some nets while preserving the current settings,
use @samp{+@var{netlist}}.  To remove a node from some nets, use
@samp{-@var{netlist}}.
To specify a totally new set of nets, just use @var{netlist}.  What's
a @var{netlist}, you ask?  It's just a series of net numbers delimited
by commas or spaces.  For example, if the node is currently in
net 0 and 2, and you wish to add it to net 5, type @samp{+5} when asked
for the nets you want to use.  To remove a node from net 0 (the
default net), type @samp{-0}.

@item [V]iew node configuration
This command prints a quick summary of the settings for
this node.

@item e[X]it net editing
This exits back to the Net menu.

@item [Z]- set l-d poll count
You can tell Fnordadel how many times you'd like it
to attempt to call an l-d system during an event before giving
up, hence this command.  Normally the system will be called
until Fnordadel obtains a carrier, and then will not be
called again during that session, whether the call was a
complete success or not.  This command overrides that; just
specify the number of calls.
@end table

@node Roomsharing, Mail Routing, Editing Nodes, Networking
@section Roomsharing
@cindex Sharing rooms
@cindex Room sharing

For most systems, the primary purpose of networking is to share
rooms.  Rooms designated as shared (or ``networked'') by the Sysop will
have all messages entered in them sent to the systems with which he has
shared the room; the other systems have, presumably, set up the same
thing, and so you end up with a sort of super-room spanning several
@sc{bbs}es.  (There are zillions of little exceptions and modifications to the
above description, which we'll let you discover for yourself.)

@node How to share a room, Topography and backboning, Roomsharing, Roomsharing
@subsection How to share a room

To make a room shared, you need to edit the room.  This
is accomplished by @code{.A(ide) E(dit)} while in the room in question;
you must have Aide status (and be logged in, naturally) to use this.  In
this menu you'll find a few useful commands, detailed here.
(For more on the room edit menu, see @ref{The .A(ide) command}, and
@ref{Sysop room-editing commands}.  These are the commands we're
interested in here:
@cindex Aide room edit menu
@cindex Room edit menu
@example
[S]hared
[U]nshare
[Y]- toggle backbone status
[N]et readable
[Z]- autonetted room
[P]ermanent
@end example

@table @code
@item [S]hared
Use this command to make a room shared to start
with, and also to add new systems to the shared list for
this room.  When you hit @samp{S} you'll be asked if you want
to make the room shared; answering ``no'' will make the room
not shared and return to the menu.  (If the room was shared
before, it will still be made unshared, but no nodes will be
removed from the shared list for the room.  This may cause
strange behavior, so be careful.)

If you answer ``yes'', Fnordadel will ask for a
list of net nodes with which to share the room.  Typing
a @samp{?} will list the choices available to you; systems
must be in your net-list, obviously, before you can share
a room with them.  Simply enter the name(s) of the nodes, one at a time,
with which to share the room, and enter a @samp{<CR>}
with no node name at the prompt to finish.

@item [U]nshare
Use this command to remove one or more systems
from the sharing list for this room.  Simply type their
name(s), one at a time, and finish with a @samp{<CR>} at the prompt.  If you
want to make the room completely unshared, i.e., not a
network room any more, use this command to disable each
node currently connected to the room.  Then use @code{[S]hare}, and answer
``no'' to make the room non-networked.

@item [Y]- toggle backbone status
This command lets you turn backboning on
or off for one or more nodes with which the room is being shared.
@xref{Topography and backboning}, for more on backboning.

@item [N]et readable
This command tells Fnordadel whether files can
be requested from this room over the network.  It has no
effect if the room is not a directory room, obviously.
If you set the room to be not network readable, then any
and all file requests for this room will be refused.

@item [Z]- autonetted room
In a normal shared room, messages are only saved as
Networked messages if the authors have net privileges; this
can, however, be overridden using the
@cindex Auto-net (room type)
@dfn{autonet} feature.
If a room is autonet, all messages entered in it are saved
as net messages, regardless.

Use this with caution.  Especially if the room is a
long-distance networked room, you could be in for a rude
shock if a ruggie phones and dumps a load of rubbish into
it---you'll pay to send it all out over the net, and all
the other systems sharing the room will likely be very
peeved.

@item [P]ermanent
This is not strictly a networking option, per se,
but it rates a mention.  If a room is shared, you'll likely
want to make it permanent to stop Fnordadel from
automatically expiring it if it empties of messages.  (Say,
if you haven't managed to call the feed for a while, or
whatever.)  Other systems tend to get peeved if shared
rooms start dropping off your system without any advance
warning, since their @code{Aide>} rooms will fill up with warnings
when they attempt to resume sending messages.
@end table

@node Topography and backboning, The loop-zapper, How to share a room, Roomsharing
@subsection Topography and backboning
@cindex Network topography
@cindex Backboning
@cindex Network backboning
@cindex Topography, network

The standard room sharing method, used for most
local connections, is for every system carrying a given room to
share the room with all other systems carrying it.  This kind of
arrangement would look like this:
@example
@group
        ---NodeA---          Every system is sharing the room
       /     |     \         with every other system.
  NodeB------)-----NodeD
       \     |     /
        ---NodeC---
@end group
@end example
The main advantage in this setup is that it's quite
robust.  If a system suddenly drops off the net, it won't disrupt
anything (topography-wise, that is; people will probably notice, but it
won't necessitate any change in the room sharing method.)

However, it's not very efficient in terms of aggregate
time spent doing networking.  Whenever there are new messages in
the shared room, each system has to call all the others.  In
addition, this method is totally insane if the systems are not
local to each other, or if there is a large number of
systems sharing the room.  So, backboning was invented.

Backboning allows network messages to be passed on to another
node even if they weren't entered on your system.  More
specifically, if you turn backboning on for a given system, say @var{foobar},
in a given room, all messages received by your system (except
from @var{foobar} itself, of course) in that room will be sent
out to @var{foobar}, in addition to all messages entered locally
on your system.

What this does to the net map is allow much greater
flexibility in connections.  First, here is an example which employs a
central hub system with lots of little ``spokes'':
@example
@group
      NodeI  NodeB  NodeC          NodeA shares the room with
          \    |    /              all systems, while all the
           \   |   /               other systems share the
  NodeH----NodeA(Hub)----NodeD     room only with NodeA.  NodeA
           /   |   \               turns backboning on for all
          /    |    \              systems; the other systems
      NodeG  NodeF  NodeE          do not use backboning.
@end group
@end example
This arrangement will basically shift the bulk of the net load
to NodeA.  The other nodes will not know that any backboning is
going on; they will simply share the room in the standard manner
with NodeA.  NodeA is responsible for passing all of the other
systems' messages on to all the other systems by turning on
backboning.

This works pretty well in local situations, and in long-distance
situations where the cost of calling NodeA is not much
different than calling any one of the other nodes.  No node is ever
more than two hops away from any other, and so propagation times
are good.

In local situations you might want to use this arrangement
to reduce the aggregate time spent in net mode by concentrating it
on NodeA; the other systems will only have to make one net call
every time new messages are entered, instead of many calls.
However, you've probably noticed a drawback---if NodeA ever
disappears, the sharing scheme has to be redone, possibly by
promoting one of the other systems to be the hub.

In long-distance situations, there are often more cost-effective
ways of arranging things.  Here's another example:
@example
@group
  NodeC                NodeH          Nodes B, C, F, G and H
    \                   /             share as normal;
     \                 /              Nodes A, D, and E flag
    NodeA---NodeD---NodeE---NodeG     all other systems as
     /        |                       backboned.
    /         |
  NodeB     NodeF
@end group
@end example
This arrangement allows NodeG, for example, to net with
NodeE instead of a (possibly more distant) hub like NodeD.  It
allows Nodes A, B and C to rely on NodeD for their feed (we assume
in this example that A, B, C and D are all local to each other.)
(In this case, it would be nice if the Sysops of A, B and C helped
with NodeD's phone bill.)

There are many variations on the above examples; the
guiding rule is that if you wish to pass messages on to another
system, turn backboning on for that system.  But be @emph{very very}
careful that loops are not introduced in the net topography, or
you'll have a ``vortex''.
@example
@group
        NodeC         NodeH          Nodes B, C, F, G and H
         /\            /             share as normal;
        /  \          /              Nodes A, D, and E flag
    NodeA--NodeD---NodeE---NodeG     all other systems as
     /       |                       backboned.
    /        |
  NodeB    NodeF
@end group
@end example
This modification of the previous example illustrates how a vortex can
happen.  NodeA and NodeD are each backboning a room to all their net
connections.  NodeC incorrectly decides to share the room with both
NodeA and NodeD.  Thus, every message entered on NodeC is sent to both
NodeA and NodeD.  But because NodeA and NodeD backbone the room to
each other, they also send all of NodeC's messages to each other.  NodeD
will also send the duplicates out to NodeE, which will propagate them to
its local connections.  This obviously causes a lot of duplication (and
expense, if there are any long-distance connections).  To automatically
detect and eliminate this vortex problem, a loop zapper was developed.

@node The loop-zapper, Shared room aliasing, Topography and backboning, Roomsharing
@subsection The loop-zapper
@cindex Loop-zapper
@cindex Network loop-zapper

With the advent of backboning came sloppy net management.
(Well, we suspect that the sloppy net management was around before,
but it never had such a good opportunity to manifest itself.)
Anyway, if your room sharing arrangement has a loop in it,
you have what we in Edmonton dubbed a
@cindex Vortex
@dfn{vortex}.  (The term appears
to have gained national popularity.)  The loop-zapper is a brute-force
method of stopping vortexes.

The way it works is pretty simple.  Each incoming networked
message has in it the node ID of the originating system, the
date and time on which the message was created, and possibly a message ID
number from the system that originated the message.  Fnordadel keeps a
database in which it stores the node IDs of all systems from which
it has ever---directly or indirectly through backboning---received
a message.

For each node ID, Fnordadel then records the date of the latest message to be
received, and what its message ID number was (if any; STadel does not pass
along such information, but Cit-86 and its clones for other machines
do, as does Fnordadel).  Moreover, this is done in each room
in which messages have been received.  So
when new messages come in, the node IDs, dates, message ID numbers
and rooms of the
messages are checked against the loop-zapper database.  If a
message
@itemize @bullet
@item
is dated earlier than the latest one received in that room
from that node, and
@item
has a lower message ID number than is recorded in the database
@end itemize
@noindent
it is assumed to be an old message coming back again, and will be rejected.
A message to that
effect will be printed on the screen (and in the net-log, if you're
keeping one.)

To enable the loop-zapper, either define the @file{ctdlcnfg.sys}
@pindex +zap (citadel)
variable @code{zaploops} to @samp{1}, or invoke @code{citadel} with the command
line argument @samp{+zap}.  The loop-zapper database is kept in your
@vindex netdir
@code{#netdir} as @file{ctdlloop.zap}.  If you happen to delete this file,
you'll have to reconfigure and start the loop-zapper again.  The
loop-zapper will be built as the messages come in; you can also
build a loop-zapper which reflects your current message base by
running the utility @code{makezt}.  The contents of your loop-zapper
@pindex makezt
@pindex scanzt
database may be viewed by using the utility @code{scanzt}.  See the
respective man pages for directions on using these programs.

Fnordadel tries to be smart about detecting truly looped
messages, versus ones that are abnormal but not duplicates.  This is
why it checks both the date/time stamp @emph{and} message ID number of each
message, and only rejects those where both values are older than
the database shows.  For example, it's possible for a glitch or system crash on
another system to cause it to start sending you messages with
message ID numbers that look old; but if
the dates are new, the messages will be accepted, not rejected, on the
assumption that the other system's message ID counter got reset to a value
lower than before.

Likewise, the clock may have been screwed up on some other system (e.g., its
clock got set to some point in the future, some messages were sent out, and
its clock is now back at the correct
value, or else it got set to some point in the past and hasn't been
corrected yet).  Your loop-zapper database will thus show a date/time
that is greater than the one on the incoming messages, but as long as
the messages have new message ID numbers, they will be accepted, not rejected.
Note that no version of STadel ever sends the message ID number, so
the loop-zapper only has the date/time stamp to work with.  Thus it's
easier for Fnordadel to mistakenly start zapping messages from an
STadel, if that node's clock got messed up.

The Fnordadel loop-zapper database is also self-correcting
to some degree.  When any message is accepted in a room, both its
date/time stamp and message ID number are recorded as being the newest ones
seen, even if they are lower than what was there before.  In this way,
your database will weed out incorrect date/time values, or message ID numbers.
It can't weed out both if they occur simultaneously, though; if a new
message comes in and has the bad luck of having an old date/time and
an old message ID number, the loop-zapper will reject it.

If you ever have
a node get screwed up and the database doesn't seem to correct itself,
the only way to stop Fnordadel from zapping all the node's messages
is to delete your @file{ctdlloop.zap} file and start from scratch.  Run the
@pindex makezt
@code{makezt} utility to build a new database from your current message
base, or just let Fnordadel run and accumulate new information over
time.

From time to time, your system may incorrectly zap a small
number of messages from one or more nodes, and then return to normal.
Zapped messages can be saved off-line if you so desire
(see @code{keepdiscards} in @ref{Optional parameters}.)
You may then read through them and optionally delete them
permanently or tell Fnordadel to integrate them into your message
base (if they look like they were zapped in error).  @xref{The Net Menu},
for instructions on these commands.

Although the loop zapper is quite smart, there's currently one glitch in it.
You may notice that if two identical messages come in during the same network
call, the zapper will let both of them all through.  Hey, so it's only close
to perfect@dots{}

@node Shared room aliasing, A few hopefully wise words, The loop-zapper, Roomsharing
@subsection Shared room aliasing
@cindex Network room alias
@cindex Room alias
@cindex Aliasing shared rooms
@cindex Shared room aliasing

If you don't like the standard name by which a shared
room is known on the network and would like to have that room
differently named on your system, you can accomplish this using
shared room aliasing.

Simply put a file called @file{alias.sys} in your
@vindex netdir
@code{#netdir}.
It should consist of @samp{<TAB>}-separated fields as follows:
@example
<@var{system}> <@var{roomname}> <@var{alias}>
@end example
@table @var
@item <system>
is the name of the system to which the alias
will apply; the special name @samp{%all} makes the alias apply to
any and all systems with which you share the room.
@item <roomname>
is the name of the room on your system.
@item <alias>
is the name of the room on the other system(s).
@end table

We actually recommend against using the aliasing feature
unless there's a really good reason for doing so.  The standard
room names are usually fine, and more importantly, it's possible
to alias a room to another name and then share the room with
another system; the Sysop of the other system may not realise that
the room he's getting from you is the same as the standard net
room and may decide to share it with yet another system in such a
way as to create a vortex.  So if you use this feature, be very
careful.

Also note that if you are sharing aliased rooms with a system, and
change the name of that system in your net list, you must exit
Fnordadel and edit @file{alias.sys} to update it with the system's
new name.  If you don't, Bad Things will happen.

@node A few hopefully wise words,  , Shared room aliasing, Roomsharing
@subsection A few hopefully wise words

@itemize @bullet
@item
Be considerate when sharing or unsharing rooms with a
system.  If you tell another Sysop to share a room with
you, make sure you've shared it with him, or his @code{Aide>}
room will be flooded with messages reporting that your
system isn't sharing the room with his.
@item
We've already mentioned this, but it bears repeating
any number of times:  Be careful when using backboning,
and when sharing rooms in general.  Make sure you
understand the topography of the room in question before
messing about; you don't want to cause a vortex, do you?
<PROD>  No, you don't.
@item
Please try to police the net rooms.  This applies
especially to the national networked rooms, which cost
people money to transport.  If you have a twit or two
who are entering stupid messages (or, worse, ``vandalism''
type of stuff like 10K of profanities and so on), it is up
to you to stomp on it as soon as possible.  Moreover,
you must also be on the lookout for what Citadelians
refer to as @dfn{room drift}; if users on your system start
talking about Pascal programming in a networked Religion
room, you must put a stop to it.  Please be considerate
for your fellow Sysops downstream.
@item
You should be aware that there are some incompatibilities between
systems descended from STadel and those directly descended
from Citadel-86.  We are working on eliminating them all in
Fnordadel, and hope eventually to make Fnordadel a
seamless connection between the STadel network and the Cit-86
network.  For the time being, not everything works perfectly.
@xref{Networking with Citadel-86}.  As for normal room sharing, you
should have only one real problem any more:  Cit-86 messages
can only be 7500 characters long, while STadel and
Fnordadel messages can be 10000 characters long.  Thus
long-winded people posting on your system will get cut short
if the messages migrate over to a Cit-86.  This could cause
some confusion.
@end itemize

@node Mail Routing, Networking with Citadel-86, Roomsharing, Networking
@section Mail Routing
@cindex Routing network mail
@cindex Network mail routing
@cindex Mail routing, network

Another popular use for the Citadel network is for private mail.
In the simplest case, that of sending mail to another user on the same
system, mail delivery is an understandably easy job.  When you want to
send mail to a user on a system which connects directly with yours, it's
also a pretty easy thing.  However, when you want to route mail through
one or more intermediate nodes before it reaches its destination, things
get a little tricky.  This section details a few helpful features
designed to make mail routing simpler and more effective.

@node Net addresses, Path aliasing, Mail Routing, Mail Routing
@subsection Net addresses
@cindex Network addresses
@cindex Addresses, network

When you go to the @code{Mail>} room and hit @code{[E]nter}, the
system asks you to tell it to whom you want to send the mail.
If the mail is going to be a networked message, you have two
ways in which the address can be specified.  One is using @samp{@@}
notation, and the other is using explicit
@cindex Bangpaths
@cindex Network addresses
@dfn{bangpaths}, which
have as their distinguishing feature the @samp{!} character as a
separator.  The two forms produce identical results; it's just a
matter of taste, really.

The @samp{@@} form is as follows:
@example
@var{user}@@@var{system}
@end example
@noindent
which means that you wish to send the mail to the user
named @var{user} on the node called @var{system}.

The bangpath form is like this:
@example
@var{system}!@var{user}
@end example
@noindent
which means the same thing as the previous example.

If you want to send mail through several nodes, you'll
have to provide a `To:' address something like this:
@example
node_a!node_b!node_c!user ,
@end example
@noindent
or perhaps
@example
node_b!node_c!user@@node_a
@end example
@noindent
As you'll notice, the @samp{@@} and @samp{!} forms can be mixed.
The two examples above both address the mail to a user on
@samp{node_c}, which (we happen to know) is reachable by a direct
path from our system to @samp{node_a} to @samp{node_b} to @samp{node_c}.

Your system may also receive routed mail from other
systems with which it networks.  If the mail is destined for a
user on your system, then it is delivered to that user and the
message stops.  But the message may be addressed to someone on a
system further on.  If you want your system to be able to pass
such mail on, you'll have to make sure that the @file{ctdlcnfg.sys}
variable
@vindex forward-mail
@code{#forward-mail} is defined as @samp{1}.  If it's @samp{0}, your
node will simply reject all routed mail.

@node Path aliasing, Hubbing, Net addresses, Mail Routing
@subsection Path aliasing
@cindex Path aliases
@cindex Network path aliasing

So, forming net addresses is easy, right?  But it's a
pain to have to remember explicit addresses through half a dozen
other systems to reach the one you want.  So Fnordadel allows
you to define, once and for all (or until you change the
definition), the paths to systems.  Then when someone wants to
send mail to someone on such a system, they need only type a `To:'
field of @samp{user@@system}, and let Fnordadel figure out where
@samp{system} is.  You can also use the path aliasing feature in
strictly local situations; if you have, say, a Citadel-86 system
with a really weird nodename, you can alias it to something short
and essentially pretend that its name (for the purposes of net
mail) has changed.

The way it works:  First of all, if you want to enable
the path aliasing feature, you should define the @file{ctdlcnfg.sys}
variable
@vindex pathalias
@code{#pathalias} to be @samp{1}.  If it's @samp{0}, Fnordadel won't
even bother.  The path alias data is stored in a file called
@file{ctdlpath.sys} in your
@vindex netdir
@code{#netdir}.  When someone enters a message
addressed to an unknown node, Fnordadel looks in this file for
an alias to the unknown system.  (Note that ``unknown'', in this
context, means any system which is not in your net-list, or which
is in your net-list and is not a member of any nets.
See the @code{[U]se nets} command in @ref{Editing Nodes}.
Also note that incoming mail from other nodes is
subjected to the same treatment; Fnordadel doesn't care
whether the mail is local.)  If it finds an address, it will
substitute this into the `To:' field of the message and mail the
message off to its target.  If the message was local, there may
be special charges (in terms of ld-credits) which apply to the
message; @pxref{Optional parameters}, on the @file{ctdlcnfg.sys} variable
@vindex ld-cost
@code{#ld-cost} for one such cost.

The @file{ctdlpath.sys} file consists of @samp{<TAB>}-separated lines of the form:
@example
@var{alias} @var{path} [@var{surcharge}]
@end example
@noindent
where @var{alias} is the nodename being aliased;
@var{path} is a string defining the path to the node; and
@var{surcharge} is an optional number of ld-credits
which will be charged to the user for using the
aliasing feature.

Here is a sample @file{ctdlpath.sys}:
@example
devnull @samp{<TAB>} poopsie!%s @samp{<TAB>} 1
alberta @samp{<TAB>} dragos!myrias!%s @samp{<TAB>} 2
Backfence @samp{<TAB>} Backfence [MN] @samp{<TAB>} 0
Silly @samp{<TAB>} Silly_Cit-86_Name[MN] @samp{<TAB>} 10
@end example
@noindent
The special sequence @samp{%s} means ``the destination node''.
In this example, let's say we wanted to mail to @samp{Holly} at the
system @samp{devnull}.  We enter a `To:' field of @samp{Holly@@devnull}.
Fnordadel discovers that @samp{devnull} is not in our net-list, so
it reverts to Plan B---path aliasing.  Searching @file{ctdlpath.sys}
for an entry for @samp{devnull}, it finds that the route to @samp{devnull} is
through @samp{poopsie}; so it massages the path into @samp{poopsie!devnull}
(since the alias specified @samp{poopsie!%s}, and @samp{devnull}, the
destination system, is substituted for the @samp{%s}).  After
appending the user name to the whole thing, the `To:' field is
@samp{poopsie!devnull!Holly}; Fnordadel now spools the mail for
delivery to @samp{poopsie}.  The user who entered the mail is charged
two ld-credits---one for the fact that it's long-distance mail,
and one for the surcharge listed in @samp{ctdlpath.sys}.

Or, in the above example, if we wanted to send mail to
a user on @samp{Silly_Cit-86_Name[MN]} and didn't want to make our users
or ourselves type that, we'd simply be able to give a `To:' field
of @samp{user@@silly} and let Fnordadel worry about it; it would
check the alias file and use the entry therein to massage the `To:'
field to @samp{Silly_Cit-86_Name[MN]!user}.

@node Hubbing, Domains, Path aliasing, Mail Routing
@subsection Hubbing
@cindex Network hub
@cindex Hubbing, network

What happens if your system gets mail addressed to an
unknown node, and it doesn't have an alias defined for that node?
If you have defined the @file{ctdlcnfg.sys} variable
@vindex hub
@code{#hub}, then your
system will have a last resort.  All mail which cannot be dealt
with either by direct connection with the target system, or by
an explicit path in the message in which the first node in the
path is directly connected, or by path aliasing, will be
forwarded to the system defined as your
@vindex hub
@code{#hub}.  This system
(hopefully) will be better able to deal with the mail than yours
was, either because it is connected to more systems directly, or
because it has a more extensive path alias file than you have.

Mail which is entered locally and is forwarded to the
@vindex hub
@code{#hub} for delivery can be charged extra ld-credits based on the
setting of the @file{ctdlcnfg.sys} variable
@vindex hub-cost
@code{#hub-cost}---see
@ref{Optional parameters}.

@node Domains,  , Hubbing, Mail Routing
@subsection Domains
@cindex Domains
@cindex Network domains

Domains are supported in this version of Fnordadel, but in
a somewhat superficial manner.  Primarily for Citadel-86 compatibility,
you can set the value of a @file{ctdlcnfg.sys} parameter called
@vindex domain
@code{#domain}, to tell Fnordadel what Citadel-86-style domain you are in.
@xref{Optional parameters}.  Citadel-86 uses this field for domain mail,
a feature Fnordadel does not yet support.

We also have some additional domain support.  By placing lines beginning
with a period (@samp{.}) character into @file{ctdlpath.sys}, we can tell
Fnordadel information about what other domains we are a part of and
about how to reach other domains.  For example, consider the
following lines in @file{ctdlpath.sys}:
@example
.uucp @samp{<TAB>} foobar!%s @samp{<TAB>} 1
.citadel
.uucp
@end example
@noindent
These lines define us to be members of the @samp{.citadel} and
@samp{.uucp} domains; in addition, they specify that any mail bound for
the @samp{.uucp} domain is to be routed through @samp{foobar} (and to be
charged, in the local case, an additional ld-credit.)

Look for better domain support in later versions.

@node Networking with Citadel-86, Other Networks, Mail Routing, Networking
@section Networking with Citadel-86
@cindex Citadel-86, networking with

Originally developed by Hue, Jr., back in the early days of
Citadel-86, the Citadel networker is a fairly flexible beast.  Indeed, it
has proved so flexible that numerous Citadel developers have mutated it in
a variety of interesting ways.  A major mutator, so to speak, was David
Parsons (orc), who did STadel, from which Fnordadel is descended.  Some
of the improvements and changes resulted in incompatibilities with Cit-86
networking.

It is our intention to eliminate or work around all of these
things at some point, hopefully in the near future.  In order to make your
Fnordadel work as smoothly as possible with a Cit-86, you should set the
Cit-86 status flag for it in your net list, and ask its Sysop to set the
STadel status flag for your system in his net list.   As of this
writing, the following are the areas in which Cit-86 and Fnordadel
networking differ:

@itemize @bullet
@item
Mail routing has been done in remarkably different ways.  Cit-86
supports STadel-style mail routing as a sort of after-hack, but
don't rely on it too much.  (Similarly, don't tell your local
Cit-86 friends to rely on you too much for mail routing, either.)
@item
Fnordadel currently has minimal support for Cit-86 domains, although
it will set the domain field on locally-originating messages, and pass
through the domain field on net messages from other systems.
@xref{Optional parameters}, and @ref{Domains}.
@item
Cit-86 supports a networking option to compress network information on
the fly.  Fnordadel does not yet support this facility.  This will
probably cause you to see messages something like ``Reply BAD: <10> unknown''
during networking sessions.  This is nothing to worry about.
@item
Cit-86 doesn't use the
@vindex organization
@code{#organization} field, or pass it on to other
systems that it nets with, so in backboned shared rooms, messages
from your system will lose the
@vindex organization
@code{#organization} field the first time
they pass through a Cit-86.
@item
Cit-86 also doesn't support the STadel message subject field.
@item
Cit-86 messages are limited to 7500 characters in size, while STadel
(and its descendants) support messages up to 10000 characters long.
Thus when your messages pass through a Cit-86, they may get chopped
short.
@end itemize

The following are incompatibilities which we inherited from STadel,
but which we have fixed:

@itemize @bullet
@item
The network sendfile/file request methods used to be different;
sending files to a Cit-86 would work (and sendfiles from the Cit-86 to
you would also work), but file requesting (in either direction)
wouldn't.  This is now fixed---everything should work.
@item
Fnordadel and Citadel-86 couldn't use the Ymodem protocol
during netting; they should be able to now.
@item
The network passwords should work fine now.
@end itemize

The following things are bits of funny business between Cit-86 and
Fnordadel, but are harmless:

@itemize @bullet
@item
If a Cit-86 is backboning any rooms to your system, you may notice
that each time it nets with your system, it will attempt to send
each backboned room, whether or not there are any new messages to be
transferred.  (It will send 0 messages, basically.)  We can't imagine why
it does this, but it seems to be normal and will not cause a problem.
@item
There are net commands that Cit-86 supports but Fnordadel doesn't,
and possibly vice versa.  In particular, Cit-86 has two commands
that Fnordadel doesn't yet know about: 8 (a different form of
room-sharing) and 10 (for data compression during networking).  They
will cause messages during
networking, such as ``Reply BAD: <10> unknown'', when a Cit-86 asks your
system to carry out such a command.  These are nothing to worry about.
@end itemize

@node Other Networks, Country Codes, Networking with Citadel-86, Networking
@section Interfacing to Other Networks
@cindex Networks, other, interfacing to
@cindex Interfacing to other networks
@cindex Connecting to other networks

Using the
@vindex event
@code{#event} mechanism, custom networking software and (often)
lots of system resources, it is theoretically possible to make your
Fnordadel talk to just about any other network in existence.  Of course,
most of the custom software has never been written, so it's largely
theoretical.

STadel had a program called @code{uucall}, which was for talking to
Unix machines using the @sc{uucp} protocol, and allowed incoming and outgoing
mail and News (the Usenet analogue to rooms).  @code{uucall} is not currently
supported by Fnordadel (and thus, is not included with it); it needs
some hacking.  If anyone is strongly interested in seeing it running, let
us know---we occasionally need a bit of encouragement.  Our plans
are, tentatively, to redo the @sc{uucp} support using a different approach,
but the @code{uucall} code is there, and with a little effort could be made to
work---it worked with Fnordadel for a long time, and then broke when we
changed something or other, and we've just never gone back and fixed it.

STadel also had a program called @code{bixcall}, which was for talking
to the Byte Information eXchange (BIX).  We've never seen BIX in our
lives, so we've no way of testing it at all.  We can send a copy to anyone
running Fnordadel and you can see if it works; there isn't much we can
do to support it, though.

@node Country Codes,  , Other Networks, Networking
@section Country Codes
@cindex Country codes

Country codes are used in your
@vindex nodeid
@code{#nodeid} (@pxref{Required parameters};
they consist of one to three letters which uniquely identify your country.
The following list is considered standard; it is purloined directly from
@file{COUNTRY3.MAN}, in the Citadel-86 documentation.
@example
Abu Dhabi               AH      Afghanistan             AF
Ajman (U.A.E.)          JM      Albania                 AB
Algeria                 DZ      Andorra                 AND
Angola                  AN      Anguila                 LA
Antigua                 AK      Argentina               AR
Australia               AA      Austria                 A
Bahamas                 BS      Bahrain                 BN
Bangladesh              BJ      Barbados                WB
Belgium                 B       Belize                  BH
Bolivia                 BV      Botswana                BD
Brazil                  BR      Brunei                  BU
Bulgaria                BG      Burma (Union of)        BM
Burmuda                 BA      Burundi                 UU
Cameroon Republic       KN      Canada                  CA
Cayman Islands          CP      Central African Empire  EC
Central African Rep.    RC      Chad Republic           KD
Chile                   CF      China (People's Rep)    CN
Colombia                CO      Congo Republic          KG
Cook Islands (Rarotonga)RG      Costa Rica              CR
Cuba                    CU      Cyprus                  CY
Czechoslovakia          C       Denmark                 DK
Djibouti, Rep of        FS      Dominica                DO
Dominican Republic      DR      Dubai (U.A.E.)          DB
Ecuador                 ED      Egypt, Arab Rep. of     N
El Salvador             SAL     Ethiopia                ET
Falkland Islands        FK      Faroe Islands           FA
Fiji Islands            FJ      Finland                 SF
France                  F       French Guiana           FG
French Polynesia        FP      Fujairah (U.A.E.)       FU
Gabon Republic          GO      Gambia                  GV
Germany (Dem. Rep)      DD      Germany (Federal Rep)   D
Ghana                   GH      Gibralter               GK
Greece                  GR      Greenland               GD
Grenada                 GA      Guadeloupe (Fr. Ant.)   GL
Guam                    GM      Guatemala               GU
Guinea                  GE      Guyana                  GY
Haiti                   HC      Honduras                HT
Hong Kong               HX      Hungary                 H
Iceland                 IS      India                   IN
Indonesia               IA      Iran                    IR
Iraq                    IK      Ireland, Rep of         EI
Israel                  IL      Italy                   I
Jamaica                 JA      Japan                   J
Jordan                  JO      Korea (South)           K
Korea, Dem People's Rep KZ      Kuwait (Persian Gulf)   KT
Laos                    LS      Lebanon                 LE
Lesotho                 BB      Liberia                 LIB
Libya                   LY      Liechtenstein           FL
Luxembourg              LU      Macao                   OM
Madagascar              MG      Malawi                  MI
Malaysia                MA      Maldives                MF
Mali                    MJ      Malta                   MT
Mariana Islands(Saipan) SA      Martinique (Fr. Ant.)   MR
Mauritania, Islam Rep   MTN     Mauritius               IW
Mexico                  ME      Monaco                  MC
Mongolia                MH      Monterrat               MK
Morocco                 M       Mozambique              MO
Nauru Islands           ZV      Nepal                   NP
Nethelands Antilles     NA      Netherlands             NL
New Caledonia           NM      New Hebrides            NH
New Zealand             NZ      Nicaragua               NK
Nigeria                 NI      Norway                  N
Oman (Persian Gulf)     MB      Pakistan                PK
Panama                  PA      Papua New Guinea        NE
Paraguay                PY      Peru                    PE
Philippines             PH      Poland                  PL
Portugal/Madeira/Azores P       Qatar (Persian Gulf)    DH
Ras Al Khaimah (UAE)    RK      Reunion Islands         RE
Rumania                 R       Rwanda                  RW
Saint Kitts (WI)        KC      Saint Lucia             LC
Saint Pierre + Miquelon QN      Saint Vincent           VQ
San Marino              RSM     Saudi Arabia            SJ
Senegal                 SG      Seychelles Islands      SZ
Sharjah (UAE)           SH      Sierra Leone            SL
Singapore               RS      Solomon Islands         HQ
Somalia Republic        SM      South Africa            SA
South West Africa       WK      Spain / Canary Islands  E
Sri Lanka               CE      St Helena               HI
Sudan                   SD      Surinam                 SN
Swaziland               WD      Sweden                  S
Syrian Arab Republic    SY      Taiwan                  TW
Tanzania                TA      Thailand                TH
Togo                    TO      Tonga                   TS
Transkei                TT      Trinidad and Tobago     WG
Tunisia                 TN      Turkey                  TR
Turks + Caicos Islands  TQ      USSR (Russia)           SU
Uganda                  UG      Umm Al Qaiwan (UAE)     QA
United Arab Emirates    EM      United Kingdom / N Ire. G
United States of Amer.  US      Upper Volta, Rep of     UV
Uruguay                 UY      Venezuela               VE
Viet Nam                VT      Virgin Islands (Brit)   VB
Western Samoa           SX      Yemen Arab Rep. (San'a) YE
Yemen, People's Dem Rep AD      Yugoslavia              YU
Zaire                   ZR      Zimbabwe                RH
@end example